DUI33 289 investigate and create versioning poc #7
Conversation
…type cache, which (if it works as expected) I think is a bit more efficient
- Removed most Kit references
…n if it exists next steps: - get the version from the commit - pick a version to use if there isn't one... what would this be? hmmm should be oldest version? want to avoid duplicating the world at this stage :D - add in the conversion logic, registering the type upgrader and picking upgrades to return the actual type we want to load
- being passed along to Dict2Base() where it can be used to pick the right deserialisation target
…is the key for the type Just need to test this now with something basic.
…pgrader, just to see it all working' Also tidied some unused usings
| @@ -207,6 +209,10 @@ public class Commit | |||
| public int totalChildrenCount { get; set; } | |||
| public List<string> parents { get; set; } | |||
|
|
|||
| // should be nullable but is currently disabled here | |||
There was a problem hiding this comment.
Lets chat about this a little, there's some challenges bringing nullability syntax to graphql because the way graphql work on a "query for what you want" mechanism.
| @@ -207,6 +209,10 @@ public class Commit | |||
| public int totalChildrenCount { get; set; } | |||
| public List<string> parents { get; set; } | |||
|
|
|||
| // should be nullable but is currently disabled here | |||
| // null schema == this is old AF | |||
| public string SchemaVersion { get; set; } | |||
There was a problem hiding this comment.
This change will need to be communicated with the web team and implemented on the server end also.
Likely it would come to Version and not Commit also.
| @@ -38,6 +40,9 @@ public static partial class Operations | |||
| /// <returns>The requested Speckle Object</returns> | |||
| public static async Task<Base> Receive( | |||
| string objectId, | |||
| ITypeCache typeCache, | |||
There was a problem hiding this comment.
For non connector consumers of Core, I would like us to keep Operations.Receive
free of typecache and schema upgrading "bloat"...
Its important that we offer an accessible SDK experience for a variety of users who aren't us making connectors.
This might mean bringing its internal implementation out into a dependency injectable service...
and leaving Operations.Receive as a simple factory function only used by non DI consumers...
I have an idea for what this might look like, but lets discuss this more, because it would be good to have some clear suite of requirements for our different SDK stakeholders.
# Conflicts: # src/Speckle.Core/Serialisation/BaseObjectDeserializerV2.cs # src/Speckle.Core/Speckle.Core.csproj # src/Speckle.Objects/ObjectsKit.cs
SHOULD REMOVE "generate package"
…we are deserialising comes from
The first step with object upgrading had to be the (unexpected) act of excising Kits from the SDK. Most of Kits has now gone, what remains appears to be largely unrelated to kits.
Type Caching is now done with a new ITypeCache, an AbstractTypeCache and and ObjectsTypeCache. In theory, because this is injected down to Receive, it is possible to continue doing a kits like thing, by passing in a different TypeCache. By default the ObjectsTypeCache is caching all types that are derived from Base and found in the assembly where ObjectsTypeCache exists and the base, i.e. looking in Core and Objects. This might be something we can do a bit more elegantly but it's definitely no worse than existing.
Note that some changes may relate to working with the SDK and the connectors at the same time.